home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000088_kane@sonata.cc.purdue.edu_Mon Nov 1 10:21 MST 1993.msg < prev    next >
Internet Message Format  |  1994-10-30  |  3KB
  1. Received: from sonata.cc.purdue.edu by alaska.et.byu.edu; Mon, 1 Nov 93 10:21:19 -0700
  2. Return-Path: <kane@sonata.cc.purdue.edu>
  3. Received: from concerto.cc.purdue.edu by sonata.cc.purdue.edu (5.61/Purdue_CC)
  4.     id AA20957; Mon, 1 Nov 93 12:19:20 -0500
  5. From: kane@sonata.cc.purdue.edu
  6. Message-Id: <9311011719.AA20957@sonata.cc.purdue.edu>
  7. Received: by concerto.cc.purdue.edu (NX5.67d/NX3.0X)
  8.     id AA07442; Mon, 1 Nov 93 12:19:18 -0500
  9. Date: Mon, 1 Nov 93 12:19:18 -0500
  10. Received: by NeXT.Mailer (1.95)
  11. Received: by NeXT Mailer (1.95)
  12. To: yackd@alaska.et.byu.edu (Don Yacktman)
  13. Subject: version numbering (Re: release of MiscKit 1.0 miscellanea)
  14. Status: RO
  15.  
  16. > You know, one thing we never decided is how to choose
  17. > whether to bump up a major or minor revision number...hmmm...
  18. > it might be good to state some sort of policy in the charter,
  19. > don't you think? What might you suggest? If I do a major number
  20. > each time I add objects/resources, it'll go up too quickly, but
  21. > if I don't then how do I distinguish between bug fix releases
  22. > and new functionality?  Maybe something like x.y.z for the number
  23. > where z is only bug fixes, y adds functionality (new resources)
  24. > and x is >10 new resources or something like that.  Opinions?
  25.  
  26. The major.minor.maintenance form is quite common.  My opinion?
  27. Use this form, with bug fixes getting maintenance increment,
  28. minor version getting incremented on new object additions with
  29. maintenance reset to 1.  I don't agree with your suggestion
  30. about the "x" value: this may sound philosophical or metaphysical
  31. ("Use the force, Luke") but I think that the major number should
  32. stay at 1 until such a time as it should be incremented to 2; I
  33. think you (or the group) will know when it is time for that.
  34.  
  35. Another option (one which you reject, but I think would be reasonable)
  36. is to use an y.z system, where y and z are as you indicate above.
  37. A version number of 114.17 doesn't seem too ridiculous to me (the
  38. info panel for Mail.app claims the version I am using to be v95).
  39. Have you been receiving submissions at a rate which would indicate
  40. that "y" would be over 100 in two years (assuming this enterprise
  41. lasts that long)? (This is a rhetorical question, of course.)
  42.  
  43. A final thought on this: it would also be reasonable to "save up"
  44. a few bug fixes or new submissions to put in a new release, rather
  45. than a new release every week with one or two minor bugs fixes
  46. (at the extreme).  A variant on the numbering scheme above arises
  47. out of this: the version number could be the date of release.
  48. For instance, if you were to decide to do a release-a-month, the
  49. version number could be 1993.11, 1993.12, 1994.1, .... or quarterly
  50. might be 1993.4, 1994.1, 1994.2, ...  Intermediate releases (for
  51. serious bug fixes for example) could be designated with letters,
  52. 1993.4a, 1993.4b, ...  The *.sources.* newsgroups work on a system
  53. like this (but, issue/number).
  54.  
  55. There are many varieties of version numbering schemes.  The important
  56. thing with any version numbering system is that it be clearly
  57. monotonically increasing.  The rest is just convention or personal
  58. preference.  People are generally intelligent creatures who can
  59. adapt and figure out what is going on.
  60.  
  61. Christopher